任何重要的軟體開發工作都需要執行多種不同的活動：分析、使用者體驗設計、開發、測試等。活動導向團隊圍繞這些活動組織，因此您有專門的團隊負責使用者體驗設計、開發、測試等。活動導向承諾許多好處，但軟體開發通常最好使用結果導向團隊。

當透過多個參考存取相同的記憶體位置時，就會發生別名。這通常是件好事，但它經常以意外的方式發生，導致令人困惑的錯誤。

這是已經存在很長一段時間的反模式之一，但似乎在目前特別流行。我與 Eric Evans 聊過這個問題，我們都注意到它們似乎越來越受歡迎。作為適當領域模型的強力推廣者，這不是一件好事。

Andrew Koenig 最早於 JOOP 的一篇文章中創造了「反模式」一詞，遺憾的是這篇文章並未在網路上公開。基本概念（根據我的記憶）是反模式在您開始時看起來像個好主意，但會讓您陷入困境。從那時起，這個術語經常被用來表示任何壞主意，但我認為最初的重點更有用。

這是朋友的朋友講的故事。我敢肯定這是真的，至少在某個地方。

雙峰 IT 是錯誤的觀念，認為軟體系統應該分成這兩個不同的類別進行管理和控制。

• 前端系統（參與系統）應最佳化以進行快速功能開發。這些參與系統需要快速回應變動的客戶需求和商業機會。應容忍缺陷，因為這是快速開發週期必要的成本。
• 後端系統（記錄系統）應最佳化以確保可靠性。作為記錄系統，重要的是不要出現會損害企業的缺陷。因此，您會減緩變更速度。

Call Super 是一種輕微的異味（或反模式，如果您喜歡），時不時會出現在 OO 架構中。它的症狀很容易發現。您從超級類別繼承以插入某個架構。文件說明類似「若要執行自己的操作，只需對 process 方法進行子類化。但是，重要的是要記得使用對超級類別的呼叫來啟動您的方法」。範例可能是類似下列內容。

現代應用程式伺服器經常宣傳的功能之一是它們在叢集中提供故障轉移。叢集會改善應用程式的可靠性，如果您的其中一個伺服器發生故障，您還有一些伺服器可以為您的客戶服務。故障轉移可以增加更多可靠性，如果伺服器在互動過程中發生故障，叢集可以將該互動移至另一部伺服器。

但是，這可能會造成問題。

每當兩個或三個值聚集在一起時，將它們變成 $%#$%^ 物件。

-- 我（使用語音會更有趣）

這是重構書籍中我最喜歡的 CodeSmell 之一。當您不斷看到相同的幾個資料項目一起傳遞時，您就會發現它。開始和結束是資料群組想要成為 範圍 的一個好範例。資料群組通常是原始值，沒有人會想到將其變成物件。

（這是一個新增到你的字典中的字彙。）

令人厭惡的（形容詞）：不可測試的軟體。

儘管我們很容易習慣它，但顯然軟體開發界在多元性方面存在一些嚴重問題。我的意思是，與一般民眾相比，我們在人口比例上有一些顯著差異。最明顯的差異之一是女性比例低，這在世界各地都是如此（儘管在中國明顯較少）。在我花費大量時間的美國，非裔美國人的缺乏也很明顯。關於為什麼會存在這種失衡以及可以採取哪些措施，已經有許多文章寫過。但這裡我想專注於一個更基本的問題 - 這重要嗎？

前幾天我在處理一些書中的範例程式碼。我做了一些變更，讓所有東西都正常運作，執行測試，並將其提交到我的個人儲存庫。然後我轉到另一個區域並做了一些變更 - 結果前一個區域中出現了一些意外的測試中斷。現在，執行自動化測試的一部分目的是找出意外的中斷，但這本書的程式碼有完全獨立的區域。這很奇怪。

敏捷方法的一種常見且可能是主要的實務，是為正在建構的軟體開發一個功能清單（通常稱為故事）。這些功能會透過索引卡、工作佇列、燃盡圖表、待辦事項清單或任何你選擇的工具來追蹤。

最近我聽說許多專案都出現了一個問題。它的運作方式如下

• 他們想要使用敏捷流程，並選擇 Scrum
• 他們採用 Scrum 實務，甚至可能是原則
• 過了一段時間，進度緩慢，因為程式碼庫一團糟

標記參數是一種函式參數，會根據其值指示函式執行不同的操作。想像一下我們想要預訂一場音樂會。有兩種方法可以做到這一點：一般和高級。若要在此處使用標記參數，我們最終會得到類似以下的宣告方法

有時候，當我處理某些資料時，那些資料比我預期的更精確。有人可能會認為這是一件好事，畢竟精確度很好，所以越多越好。但隱藏精度可能會導致一些細微的錯誤。

如果你一直關注我的同事 ThoughtBloggers，你就會知道，其中 一個我的機器人好像燒壞了，澳洲的陽光顯然會讓這些瑞典模型變焦。

Jon 對 資料傳輸物件感到厭煩，但並非 DTO 是件壞事，就像任何模式一樣，它們在特定情況下很有用。模式總是有兩個部分：如何和何時。你需要的並非只是知道如何實作它們，還必須知道何時使用它們以及何時不理它們。

我最近一直在研究 JavaScript，而讓我印象深刻的一件事是使用相同函式名稱來表示 getter 和 setter。因此，如果你想在 jQuery 中找出你的廣告欄高度，你會使用 $("#banner").height()，而如果你想變更高度，你會使用 $("#banner").height(100)。

這個慣例對我來說很熟悉，因為 Smalltalk 使用過它。你可能會使用 banner height 取得一個值，並使用 banner height: 100 來變更它。知道它是 Smalltalk 慣例就足以讓我喜歡它，因為我對那門語言有著遙遠但持久的愛。但即使是最好的事物也有缺點，我無法隱藏我對這種程式碼風格的反感。

IT 部門常見的問題是，是否要透過建置自訂軟體或購買套件來提供功能。在我從事程式設計以來，關於如何做出此選擇的爭論一直持續著。我對此的基本立場建立在 UtilityVsStrategicDichotomy 上。簡而言之，這表示如果您支援的業務流程是您的競爭優勢的一部分，則您應該建置自訂軟體；如果不是，則您應該購買套件，並調整您的業務流程以符合套件運作的方式。

儘管我的意見顯然優異，但似乎沒有很多公司這麼做。他們常常忽略二分法，這是其中一個問題。但我想在此關注的問題是，當他們購買套件時常見的陷阱。

軟體的優點之一是，人們似乎想要它，而且想要得很快。組織通常會要求團隊加快軟體生產速度，而且組織偶爾會尋求以真正展現其承諾的方式提供協助，也就是花錢增加團隊成員。

聽過我和同事談論 FeatureBranch 的人，就知道我們不是這種模式的忠實粉絲。我們反對的一個重要部分是，分支很容易，但合併很難。我們偶爾聽到的說法是，現代 VersionControlTools 讓合併變得足夠容易，因此功能分支是值得的。

我習慣建立 Neologism 來描述我在軟體開發中看到的事物。這是這個領域的作家常見的習慣，因為軟體開發仍然缺乏許多有用的術語。建立術語的一個問題是，術語容易失去其意義，這是一個語意擴散的過程，也就是使用我們術語中另一個潛在的附加項目。

幻燈文件是幻燈片組和文件之間的交叉產物。其想法是，您可以將單一幻燈片組用於簡報中的幻燈片，並作為講義供人們在簡報後閱讀。問題在於，這兩個需求會對您的幻燈片產生截然不同的要求，因此您無法同時滿足這兩個需求。結果是，幻燈文件通常在這兩個方面都失敗。

讓生產伺服器持續運作可能是一項繁瑣的業務。您必須確保作業系統和任何其他依賴軟體都正確修補，以使其保持最新狀態。託管的應用程式需要定期升級。通常需要進行組態變更，以調整環境，使其能有效率地執行，並與其他系統正確通訊。這需要一些命令列呼叫、在 GUI 畫面之間跳轉，以及編輯文字檔案的組合。

結果是一個獨特的雪花 - 對於滑雪場來說很好，但對於資料中心來說很糟。

故事測試是 BusinessFacingTests，用於描述和驗證作為 UserStory 一部分提供的軟體。當一個故事被闡述時，團隊會建立幾個故事測試，作為故事的驗收標準。故事測試可以合併到軟體的回歸套件中，並提供從需求 (使用者故事) 到測試，以及 (透過執行) 到系統行為的可追溯性。故事測試通常是 BroadStackTests。

我發現這是一種令人遺憾的常見架構風格。您的公司購買了一些非常昂貴的基礎設施軟體。然後有人告訴您，即使它不適合該專案，而且會讓您付出額外的努力，您也必須在專案中使用它。在為它支付了所有費用後，您不希望它浪費掉，對吧？

由於我的職業已轉為全職作者，我常擔心自己會與日常軟體開發的現實脫節。我已看過其他知名人物失去與現實的聯繫，我害怕自己也會步上後塵。我對此最主要的抵抗來源是 Thoughtworks，它就像一劑定期的現實藥劑，讓我腳踏實地。

Thoughtworks 也充當一個來自現場的想法來源，我很享受撰寫同事發現並開發的有用事物。這些通常是有用的想法，我希望一些讀者能使用。我今天的題目並非如此令人愉悅。這是一個問題，而且我們沒有答案。

在軟體世界中，「瀑布」通常用來描述一種軟體流程風格，與反覆或敏捷風格的想法形成對比。就像軟體中的許多知名術語一樣，它的意義定義不明確，起源也模糊不清 - 但我發現它的基本主題是根據活動將大量工作分解成階段。